How to use CC_DENY and CC_ALLOW of the CSF firewall - centos
How to use CSF Firewall features:
CC_DENY
and
CC_ALLOW
I am getting a lot of attempts to access ssh, so I would like to block all countries, instead of having to add them one by one.
Of course, leave only my country as allowed.
UPDATE 2020-02-13
After researching a lot I found that:
CC_DENY = If you want to block the country, this is where you must enter the country code.
CC_ALLOW = Here is the catch, if you put your country's code here, it will do the general release, including firewall ports. In other words, your country will not respect any rules of your firewall.
I will leave my contribution of country codes. REMOVE YOUR CODE.
CC_DENY = "AD,AE,AF,AG,AI,AL,AM,AO,AQ,AR,AS,AT,AU,AW,AX,AZ,BA,BB,BD,BE,BF,BG,BH,BI,BJ,BL,BM,BN,BO,BQ,BS,BT,BV,BW,BY,BZ,CA,CC,CD,CF,CG,CH,CI,CK,CL,CM,CN,CO,CR,CU,CV,CW,CX,CY,CZ,DE,DJ,DK,DM,DO,DZ,EC,EE,EG,EH,ER,ES,ET,FI,FJ,FK,FM,FO,FR,GA,GB,GD,GE,GF,GG,GH,GI,GL,GM,GN,GP,GQ,GR,GS,GT,GU,GW,GY,HK,HM,HN,HR,HT,HU,ID,IE,IL,IM,IN,IO,IQ,IR,IS,IT,JE,JM,JO,JP,KE,KG,KH,KI,KM,KN,KP,KR,KW,KY,KZ,LA,LB,LC,LI,LK,LR,LS,LT,LU,LV,LY,MA,MC,MD,ME,MF,MG,MH,MK,ML,MM,MN,MO,MP,MQ,MR,MS,MT,MU,MV,MW,MX,MY,MZ,NA,NC,NE,NF,NG,NI,NL,NO,NP,NR,NU,NZ,OM,PA,PE,PF,PG,PH,PK,PL,PM,PN,PR,PS,PT,PW,PY,QA,RE,RO,RS,RU,RW,SA,SB,SC,SD,SE,SG,SH,SI,SJ,SK,SL,SM,SN,SO,SR,SS,ST,SV,SX,SY,SZ,TC,TD,TF,TG,TH,TJ,TK,TL,TM,TN,TO,TR,TT,TV,TW,TZ,UA,UG,UM,US,UY,UZ,VA,VC,VE,VG,VI,VN,VU,WF,WS,YE,YT,ZA,ZM,ZW"
CC_ALLOW = ""
Use CC_DENY to block countries in your server
or
Use CC_ALLOW to whitelist countries in your server
Allowed values are two-letter ISO Country Code(s) e.g. "US,GB,DE"
Caution must be taken when using this setting as you might completely block yourself or your visitors.
A better solution might be to change the default ports of services e.g., SSH port.
Related
How do I send a Diameter message to an IP other than Destination-Host's value in mobicents
In all Diameter implementations I saw, the messages originating from the server is always sent towards the DNS resolved IP address of whats in the Destination-Host AVP. But, in commercial servers, we see an option to configure a DRA or a DEA which takes in all the messages and routes them. Thus, when it comes to the mobicents diameter stack, this approach is sometimes hard to do. I can anyway re-configure the hosts file so that the message ends up in a DRA/DEA, yet, its a pain. I see no option to send these messages to a central diameter agent which will take care of all the dirty work for me. The next issue is, if I plan to create such a DRA/DEA, the stack does not accept messages to a different host. Where, the message's Destination-Host parameter might contain a different hostname than ours. (which would be the ultimate destination it needs to go) Is there a hack to achieve this without meddling with the internals of the jdiameter code and RA code?
If you change jdiameter's config to something like this: <Network> <Peers> <Peer name="aaa://127.0.0.1:21812" attempt_connect="false" rating="1" /> <Peer name="aaa://CUSTOM_HOST:4545" attempt_connect="false" rating="1" /> </Peers> <Realms> <Realm name="custom.realm" peers="CUSTOM_HOST" local_action="LOCAL" dynamic="false" exp_time="1"> <ApplicationID> ... </ApplicationID> </Realm> </Realms> </Network> In your sbb, then you'll need to create a client session providing your custom realm using this method: DiameterCCAResourceAdaptor.CreditControlProviderImpl.createClientSession(DiameterIdentity destinationHost, DiameterIdentity destinationRealm) Example: ccaRaSbb.createClientSession(null, "custom.realm") where ccaRaSbb is a CreditControlProvider instance (resource adaptor interface) finally, when creating your CCR, the method CreditControlClientSession.createCreditControlRequest() will use the session' realm to find an available peer previously configured. Let me know if this makes sense to you
Posting the method I used to solve this problem. As it turns out its not possible out of the box to send a diameter message towards a peer which is not configured in the stack's jdiameter-config.xml file. For me, the option to alter the stack in this case was also not feasible. So I devised a workaround for the problem by co-operating with the DRA we have. (most DRA's should be able to handle this method) I added two custom AVPs to the outgoing request, namely Ultimate-Destination-Host and Ultimate-Destination-Realm. In the DRA, I asked the admin to delete my Destination-Host and Destination-Realm AVPs and replace them with the ones created in step 1. Now, whenever I send a packet destined to other diameter peers outside the configured peer, I target them towards the DRA and set these 'Ultimate' destination AVPs. Ours is an Oracle DSR which is capable of doing this AVP manipulation. Most commercial ones should be able to handle it. Hope someone who wanted an answer for this question found this useful.
Supporting multiple languages in a REST API
I have a collection of cities for which I'm creating a REST API (my first REST API). Each city has a number of language independent things, such as founding date and population count. Cities also have things that depend on the language, such as the title and a short description. Internally the city documents have this format: { "population": 9042, "name": { "en": "Berlin", "nl": "Berlijn", // ... }, // ... } The users of my API always want to view the city info for a specific language only, and get back something like: { "population": 9042, "name": Berlin, // ... } I've made these accessible via /cities/:id/:language_code, for instance cities/123/en. Now I want to implement listing of cities: GET /cities. There the requested language is also needed. Since this would result in /cities/:language_code, I'm getting the impression putting this at the end of the url is not a good idea, and suspect I'll be better off with /en/cities/...whatever.... How is this typically done in REST APIs? Any big, nicely implemented, API out there that is a good example?
REST API's are based upon HTTP protocol, so they can use the headers, that are traditionaly used to defined the prefered locale. So I would use a Accept-Language parameter for this. # Request GET /cities/.... HTTP/1.1 Host: www.example.org Accept-Language: en,en-US,fr;q=0.6 Would give : { "population": 9042, "name": Berlin, // ... }
It depends on your clients. If the clients are applications, then #Orabîg's answer is 100% correct. If your clients are web browers, though, you should track language as a user preference. The reason is that a user might be using a non-personal machine where the browser is set to a different language, and they may not know how to or be able to change that setting. Rather than forcing them to use an unfamiliar language, you build the preference into your API. In that case, I would start with the language provided in Accept-Language until the user either identified themself. Once they are passing some identifying token in a header with each request, use that to figure out what language responses should be in.
Just to mention the related article of W3C about using headers for locale determination (not only language that seems be the original case of the question) The HTTP Accept-Language header was originally only intended to specify the user's language. However, since many applications need to know the locale of the user, common practice has used Accept-Language to determine this information. It is not a good idea to use the HTTP Accept-Language header alone to determine the locale of the user. If you use Accept-Language exclusively, you may handcuff the user into a set of choices not to his liking. For a first contact, using the Accept-Language value to infer regional settings may be a good starting point, but be sure to allow them to change the language as needed and specify their cultural settings more exactly if necessary. Store the results in a database or a cookie for later visits. Some of the potential issues include the following: Many users never change the defaults for Accept-Language. They are set when the user agent is installed. Unless they are multilingual or have some other reason to adjust language preferences they may not even know such settings exist. Hence, the user may not have ever ratified the Accept-Language setting. A user agent may send a request that specifies only a language and not a region, for example you may not get a header with de-DE, de-CH or de-AT to indicate German as spoken in Germany, Switzerland or Austria, respectively. On the other hand, you might only get de indicating a preference for German. If you were planning to use the region to decide what currency to use you are now in a bind. Your particular circumstances might allow you to make assumptions such as "Germany has 83 million people, Switzerland has 7 million but only 63% speak German, Austria has 8 million, so this user probably uses the Euro. If we're wrong we'll only offend 4.6% of our German speaking customers or just over 4 million people." Feel free to make such an assumption, if you can accept the risk. Its a lot simpler to ask the user for more information. Also, the math gets more difficult for Spanish or English, for instance. People borrow machines from friends, they rent them from internet cafes. In these cases the inferred locale may be inappropriate, and care should be taken to allow the user to select the appropriate language and locale from whatever page they are looking at. Full article: Accept-Language used for locale setting
How can I be sure an email address is unique?
There's a pub in my town whereby, if you sign up to their newsletter using their website and provide a "unique" email address, you get a free drink. On a whim, I decided to sign up a second time using myemail+one#gmail.com. It let me. I'm now sitting on a nice comfy pile of free drink vouchers. This got me thinking about a system we have here, where the email address is considered the unique identifier. Checking the code, sure enough, if we were offering vouchers in our business, someone else would be sitting pretty. The basic, stab-in-the-dark, fix is to check for the "+" character and ignore everything after it (up to the #), and compare using that. But I am unsure if this was the intent for the + character. Would that work? Secondly, are there any other caveats that would allow a user to sign up multiple times with a seemingly different email address, but which actually would always end up in the same mailbox? This question is language-agnostic.
While using a plus sign as an e-mail address alias is a known feature of gmail, other mailers do either not allow it or use a minus sign instead. '+' is a legitimate character to be used as part of an email address according to the RFC. The use of '.' is also a gray area. john.doe#gmail.com and johndoe#gmail.com send also both to the same email address and look different. In order to validate the uniqueness of an email address you will have to prepare a rule base for your application, keep it up to date and still expect surprises...
Notes Formula Language "#ValidateInternetAddress" Failing to Validate Properly?
We are using the following validation code to check for a valid email address formatting on a web form driving by Lotus Notes: #If((#ValidateInternetAddress([Address821]; #ThisValue)!="" | #Contains(#ThisValue; "\"") | #Contains(#ThisValue; "'") | #Contains(#ThisValue; " ")); "Please include a valid email address."; ""); Currently, if a user enters any of the following inputs, the verification throws the error message: empty field " ", ', or / character the domain portion of the email: "test.com" only # However, if a user enters test#test the form validates this as a valid email address format. Is this format considered to be a valid "Address821" format? Or is the form validating an incorrect format as a valid email address?
Yes, it technically is valid address syntax, both by past and current standards. The language in the RFC's has evolved over time: RFC-821: 3.7. DOMAINS Domains are a recently introduced concept in the ARPA Internet mail system. The use of domains changes the address space from a flat global space of simple character string host names to a hierarchically structured rooted tree of global addresses. The host name is replaced by a domain and host designator which is a sequence of domain element strings separated by periods with the understanding that the domain elements are ordered from the most specific to the most general. This isn't very precise. It doesn't explicitly say that there must be more than one element in the domain name, but it doesn't explicitly prohibit it either. But this was obsoleted by: RFC-2821: 2.3.5 Domain A domain (or domain name) consists of one or more dot-separated components. ... The domain name, as described in this document and in [22], is the entire, fully-qualified name (often referred to as an "FQDN"). A domain name that is not in FQDN form is no more than a local alias. Local aliases MUST NOT appear in any SMTP transaction. This seems to be saying that it's illegal, but actually it isn't saying that. I'll explain below, but first let's have a look at the draft standard that is intended to obsolete 2821, and which clarifies things a great deal: RFC-5321 2.3.5 Domain Names A domain name (or often just a "domain") consists of one or more components, separated by dots if more than one appears. In the case of a top-level domain used by itself in an email address, a single string is used without any dots. This makes the requirement, described in more detail below, that only fully-qualified domain names appear in SMTP transactions on the public Internet, particularly important where top-level domains are involved. ... The domain name, as described in this document and in RFC 1035 [2], is the entire, fully-qualified name (often referred to as an "FQDN"). A domain name that is not in FQDN form is no more than a local alias. Local aliases MUST NOT appear in any SMTP transaction. What this makes clear is that no dot is required in a domain name, as long as it is a top level domain. #ValidateInternetAddress cannot reasonably know whether "test" is a valid top level domain. Even if IBM programmed in the list of approved public TLD's (which IMHO would be a bad idea since it can and does change), you can in fact set up a private TLD called "test" in your own DNS. That's not the same thing as a "local alias" which the standard does prohibit. There's no rule against actual TLDs. And for that matter, it could even be a public TLD. Theoretically, the owner of a TLD could set up a mail server for the TLD. I.e., President#US, or Queen#UK. Not likely, but possible in those cases, but with all the new TLD's coming on line, I wouldn't be surprised if some of the registrars are using info#domain. I guess theoretically #ValidateInternetAddress could make the DNS call to check whether it can resolve "test" as a TLD, but the doc for that function only says that it checks the syntax of the address, and the existence of the TLD is a semantic issue, not a syntax issue.
Is it possible to include comments inside a non email host name?
I am working on a more complete email validator in java and came across an interesting ability to embed comments within an email both in the "username" and "address" portions. The following snippet from http://www.dominicsayers.com/isemail/ has this to say about comments within an email. Comments are text surrounded by parentheses (like these). These are OK but don't form part of the address. In other words mail sent to first.last#example.com will go to the same place as first(a).last(b)#example(c).com(d). Strange but true. Do emails like this really exist ? Is it possible to form hosts like this ? I tried entering an url such as "google(ignore).com" but firefox and some other browsers failed and i was wondering is this because its it wrong or is it because they dont know about host name comments ?
That syntax -- comments within an addr-spec -- was indeed permissible by the original email RFC, RFC 822. However, the placement of comments like you'd like to use them was deprecated when that RFC was revised by RFC 2822... 10 years ago. It's still marked as obsolete in the current version, RFC 5322. There's no good excuse for emitting anything using that syntax. Address parsers are supposed to be backwards-compatible in order to cover all conceivable cases, including 10-years-deprecated bits like the one you're trying to take advantage of here. But I'll bet that many, many receiving mail agents will fail to properly parse out those comments. So even though you may have technically found a loophole via the "obsolete addressing" section of the RFC, it's not likely to do you much good in practice. As for HTTP, the syntax rules aren't the same as email syntax rules. As you're seeing, the comment section from RFC 822 isn't applicable.
Just because you can do it in the spec, doesn't mean that you should. For example, Gmail will not accept that comment format for address. Second, (to your last point), paren-comments being allowed in email addresses doesn't mean that they work for URLs. Finally, my advice: I'd tailor the completeness of your validator to your requirements. If you're writing a new MTA (mail transfer agent), you'll probably have to do it all. If you're writing a validator for a user input, keep it simple: look for one #, make sure you have stuff before (username) and after (domain name), make sure you have a "dot" in the hostname string, [extra credit] do a DNS lookup of the hostname to make sure it resolves.